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REMARKS 

Applicants provide the present Amendment to address the issues raised in the 
Official Action mailed December 28, 2004. 

Status of the Claims 

Claims 1-48 are pending in the application. Claims 36-48 stand rejected under 
35 U.S.C. § 1 12, second paragraph as indefinite. Official Action, p. 2. Claims 1-48 
stand rejected under 35 U.S.C. § 102(b) as anticipated by U.S. Patent No. 5,933,831 
to Jorgenson (Jorgenson). Applicants appreciate withdrawal of the rejection based on 
35 U.S.C. §101. 

Applicants have amended Claims 12 and 24 to recite that the selective 
association of a foreign key value of a record in the relating table with a specific one 
of a plurality of related tables provides "multiple but exclusive relationships between 
tables in the relation database." This aspect of the present invention is described, for 
example, at page 8, lines 29-31 of the Specification. 

Applicants have amended Claims 36 to 48 to clarify that the type recited to the 
claims is an attribute associated with records in a table. 

The Indefiniteness Rejections 

The Official Action rejects Claims 36-48 under the second paragraph of 35 
U.S.C. § 1 12 as indefinite. Official Action, p. 2. In particular, the Official Action 
states that "it is not understood what is meant by 'associating a type with respective 
ones of the plurality of second tables.'" Official Action, p. 2. Applicants have 
removed this language from Claims 36-48. 

Applicants have also amended Claims 36 to 58 to clarify that the type is an 
attribute that may be used to associate records with tables. Thus, Claims 36 to 48 
have been amended to recite, in part, "associating, in the database, a type attribute 
with records in the first table such that the type attribute of a record in the first table 
identifies which ones of the plurality of second tables the record is associated with." 
The attribute is the type of table that is associated with the records. This type-based 
association is described in the Specification at, for example, page 8 stating: 
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As described below, embodiments of the present invention provide type based 
selective foreign key association that may be utilized to enforce a multiple but 
exclusive relationship between tables in a relational database. Foreign key 
association may be said to be type based if the selection of which one of a 
plurality of related tables the foreign key is associated with is based on some 
attributes of records in the table for which the foreign key is defined. 

Specification, p. 8, lines 24-29. Applicants submit that the use of an attribute that is 
associated with a type of table is clearly described in the Specification and in Claims 
36-48. As such, Applicants submit that the amended Claims 36 to 48 clearly satisfy 
the requirements of § 112, second paragraph as described in MPEP § 2106 

The Rejections Based on Jorgenson 

The Official Action rejects Claims 1-48 under 35 U.S.C. § 102(b) as 
anticipated by Jorgenson. Official Action, p. 3. The rejection of Claims 1-48 appears 
to cite the same portions of Jorgensen as cited in the previous Final Action. As such, 
Applicants submit that the rejection is improper for the reasons discussed in 
Applicants' previous responses, which are incorporated by reference herein. Rather 
than repeating those arguments, Applicants will address the comments of the 
Examiner in the Response to Arguments portion of the Official Action. 

In the previous responses, Applicants noted that the Official Action cited to 
Figures 3A-3C of Jorgensen as disclosing "means for selectively associating a foreign 
key value of a record in the relating table with a specific one of the plurality of related 
tables based on at least one attribute of the record containing the foreign key in the 
relating table" and this citation has not changed. Official Action, p. 4. These Figures 
describe operations for displaying a hyperlinked entity relationship diagram. 
Jorgensen, col. 2, lines 52-55. The operations of Figures 3A-3C do not provide the 
entity relationship in a database but merely provide a display of that relationship. 
Therefore, Applicants argued that nothing in the cited portions of Jorgensen discloses 
or suggests the selective association of a foreign key in a relating table with a specific 
one of a plurality of related tables based on an attribute of the record containing the 
foreign key in the relating table as is recited in independent Claim 12. Similar 
recitations to those of Claim 12 are found in Claims 1 and 24. 
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In response to this argument, the Official Action asserts that the "clickable 
foreign key icon 324" of Figure 3B of Jorgensen teaches the selective association of a 
foreign key. However, Applicants submit that displaying a clickable foreign key icon 
is not selectively associating a foreign key with a table, it is merely displaying an icon 
that represents a foreign key and the icon may be selected. The Official Action further 
asserts that the relating table is taught by the current table 314 of Figure 3B of 
Jorgensen. Official Action, p. 6. However, block 314 recites selecting an entity from 
a current table for display. Jorgensen, col. 4, lines 59-61 . Jorgensen then describes 
determining if the entity contains a foreign key and displaying the foreign key icon if 
it does. Jorgensen, col. 5, lines 11-16. The Official Action also cites to the pop-up list 
of child tables 332 of Figure 3B of Jorgensen as disclosing that the foreign key of a 
relating table is associated with a specific one of a plurality of related tables. Official 
Action, pp. 6-7. This portion of Jorgensen describes displaying an icon for a pop-up 
list of child tables if the selected entity is a parent. Jorgensen, col. 5, lines 26-35. 

While Applicants are unsure of how these cited portions of Jorgensen that 
provide for displaying relationships in an existing database, not establishing those 
relationships, could possibly be interpreted as disclosing the recitations of any of the 
independent claims of the present application, Applicants submit that, even if the 
display of a relationship is somehow interpreted as establishing the relationship, 
Jorgensen still does not disclose the recitations of Claims 1,12 and 24. In particular, 
Claims 1, 12 and 24 each recite "selectively associating a foreign key value of a 
record in the relating table with a specific one of the plurality of related tables based 
on at least one attribute of the record containing the foreign key in the relating table so 
as to provide multiple but exclusive relationships between tables in the relational 
database." Thus, foreign keys are selectively associated with corresponding related 
tables based on an attribute of the record containing the foreign key. Merely knowing 
the foreign key does not identify the related tables because the attribute must also be 
known to identify the specific one of the related tables that is associated with the 
foreign key. 

In contrast, Jorgensen describes displaying the conventional foreign key 
relationship where the foreign key points to a parent table as described in the 
background of the present application. Thus, for example, Jorgensen describes 
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displaying the clickable foreign key icon if there is a parent table for the entity of the 

current table. Jorgensen Figure 3C, block 322. The determination of whether there is 

a parent table is described with reference to block 322 and states: 

If there is no primary key on the currently selected entity, the process 
proceeds instead directly to step 322, which depicts a determination of 
whether a parent table exists for the currently selected entity. The existence of 
a parent table for the currently selected entity may be established by the 
relational database. If a parent table exists for the currently selected entity, the 
process proceeds to step 324, which illustrates displaying a clickable foreign 
key icon for the entity in the table, and then to step 326. 

Jorgensen, col. 6, lines 8-16. There is no discussion whatsoever of how the 
determination that a parent table exists is carried out other than to state that it is 
established by the database. There is no indication that the parent/child relationship is 
established by a foreign key and an attribute as is recited in Claims 1, 12 and 24. 
Applicants submit that Jorgenson does not describe how the parent/child relationship 
is established because Jorgenson does not care how it is established but only cares that 
it exists and the relationship can be displayed. This is because Jorgensen relates to 
displaying relationships in a database, not creating them. 

Jorgenson also describes displaying child tables if the current table is a parent 
table. This is described with reference to the cited block 332 of Figure 3B of 
Jorgensen. The determination of whether the current table has child tables is 
described with reference to block 330 of Figure 3B of Jorgensen. In particular, 
Jorgensen states: 

If no constraint is found for the current entity, the process proceeds 
instead directly to step 330, which depicts a determination of whether the 
entity is a parent--i.e., whether there exists one or more child tables for the 
currently selected entity. This determination may be made from the relational 
database. If at least one child exists, the process proceeds to step 332, which 
illustrates displaying a list of child tables for the currently selected entity with 
each name in the list hyperlinked to the respective child table, and then to step 
334. 

Jorgensen, col. 6, lines 26-35. Again, there is no discussion whatsoever of how the 
determination that a child table exists is carried out other than to state that it is 
established by the database. There is no indication that the parent/child relationship is 
established by a foreign key and an attribute as is recited in Claims 1,12 and 24. 
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Applicants also note that there is no discussion in Jorgensen with respect o 
using a foreign key and an attribute to provide a multiple but exclusive relationship as 
recited in Claims 1,12 and 24. While the Official Action never discusses the multiple 
but exclusive relationship with reference to Claim 1, there is a discussion of 
"enforcing the multiple but exclusive relationship between tables in a relation 
database" on page 4 of the Official Action. In discussing the multiple but exclusive 
relationship, the Official Action appears to be confused as to the nature of the multiple 
but exclusive relationship. This relationship is described with reference to Figures 2C 
through 2D of the present Specification, and is defined as "a multiple but exclusive 
relationship is one where entries in a given table may have a one-to-many or a many- 
to-many relationship to entries in exactly one of several other tables ." As is further 
described in the present Specification: 

Referring back to Figures 2C and 2D, the multiple but exclusive one-to-many 
relationship between table A and tables Bi and B2 in Figure 2C may be 
expressed if each given record in A may be restricted to only relate to a set of 
records in one and only one of tables Bi or B2. Similarly, in Figure 2D, the 
relationship may be multiple but exclusive because each given record in Table 
A may be restricted to relate to exactly one set of records in one and only one 
of tables Bi or B 2? where the set of records is defined by the corresponding 
relationship table Rj and R2. 

Specification, p. 8, line 32 to p. 9, line 5. 

The Official Action cites to Figure 2 of Jorgensen as describing the multiple 

but exclusive relationship. Official Action, p. 4. However, Figure 2 of Jorgensen 

does not appear to describe more than is described by Figures 2A and 2B of the 

present application. As discussed in the present specification, Figures 2 A and 2B do 

not describe a multiple but exclusive relationship but describe the conventional 

multiple relationships. In particular, the Specification states: 

As is seen from Figures 2A and 2B, in conventional database design for 
expressing a multiple relationship, it is possible to have a record in Table A 
relating to more than one record in more than one table from tables Bi, B 2 , B 3 , 
. . ., B m . In other words, a database management system (DBMS) may be 
unable to enforce an exclusive aspect of the one-to-many or many-to-many 
multiple but exclusive relationships. Embodiments of the present invention 
may, however, allow a DBMS to enforce the multiple but exclusive 
relationship utilizing the selective association of foreign keys as is described 
herein. 
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Specification, p. 9, lines 14. Thus, while Figure 2 of Jorgensen may describe multiple 
relationships, there does not appear to be a description of the exclusive aspect of the 
one-to-many or many- to-many relationship as is recited in Claims 1,12 and 24. 

In light of the above discussion, Applicants submit that Claims 1,12 and 24 
are not anticipated by Jorgensen. Applicants submit that the claims that depend from 
Claims 1,12 and 24 are patentable at least as depending from a patentable base claim. 

With regard to independent Claims 36, 40 and 45, these claims have been 
amended to recite that a "type attribute" is associated with records in a first table that 
identifies ones of a plurality of second tables with which the record is associated. 
Applicants submit that these recitations are not found in Jorgensen. Applicants also 
submit that recitations regarding enforcing the multiple but exclusive relationship 
between records in the second tables and the first table based on the type attribute 
associated with a record in the first table are also not found in Jorgensen for reasons 
analogous to those discussed above with reference to Claims 1,12 and 24. 
Accordingly, Applicants submit that Claims 36, 40 and 45 are not anticipated by the 
cited portions of Jorgensen. Accordingly, Applicants request allowance of Claims 36, 
40 and 45 and the claims that depend from them. 

With regard to the dependent claims, these claims are patentable at least as 
depending from a patentable base claim. Applicants also submitted in the previous 
response that certain of these claims are separately patentable over the cited 
references. These arguments have also not been addressed or refuted. In fact, the 
Official Action continues to reject the dependent claims saying that they are "default 
properties of standard OO SQL processing." Official Action, p. 4. As discussed in 
Applicants* previous response, Applicants are not claiming new properties of SQL but 
are claiming the use of database techniques to provide new functionality. Based on 
the logic of the argument in the Official Action, no software implemented invention is 
patentable if the programming language it is written in is known. Applicants submit 
that merely because the building blocks that are used to create embodiments of the 
present invention are known, that does not disclose or suggest the specific 
arrangement of those building blocks as is recited in the claims. 

For at least the reasons discussed therein, Applicants submit that the rejections 
of Claims 1-48 based on Jorgenson are improper. 
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Conclusion 

In light of the above discussion, Applicant submits that the present application 
is in condition for allowance, which action is respectfully requested. 



Respectfully submitted, 




Timothy JrX/Sullivan 
Registration No. 35,632 



Customer Number: 20792 



CERTIFICATE OF MAILING 

I hereby certify that this correspondence is being deposited with the United States Postal Service as first class mail 
in an envelope addressed to: Mail Stop Amendment, Commissioner for Patents, P.O. Box 1450, Alexandria, VA 
223L3-1450 on March U, 2005. 




Traci A. Brown 



